23 research outputs found
Towards Automatically Addressing Self-Admitted Technical Debt: How Far Are We?
Upon evolving their software, organizations and individual developers have to
spend a substantial effort to pay back technical debt, i.e., the fact that
software is released in a shape not as good as it should be, e.g., in terms of
functionality, reliability, or maintainability. This paper empirically
investigates the extent to which technical debt can be automatically paid back
by neural-based generative models, and in particular models exploiting
different strategies for pre-training and fine-tuning. We start by extracting a
dateset of 5,039 Self-Admitted Technical Debt (SATD) removals from 595
open-source projects. SATD refers to technical debt instances documented (e.g.,
via code comments) by developers. We use this dataset to experiment with seven
different generative deep learning (DL) model configurations. Specifically, we
compare transformers pre-trained and fine-tuned with different combinations of
training objectives, including the fixing of generic code changes, SATD
removals, and SATD-comment prompt tuning. Also, we investigate the
applicability in this context of a recently-available Large Language Model
(LLM)-based chat bot. Results of our study indicate that the automated
repayment of SATD is a challenging task, with the best model we experimented
with able to automatically fix ~2% to 8% of test instances, depending on the
number of attempts it is allowed to make. Given the limited size of the
fine-tuning dataset (~5k instances), the model's pre-training plays a
fundamental role in boosting performance. Also, the ability to remove SATD
steadily drops if the comment documenting the SATD is not provided as input to
the model. Finally, we found general-purpose LLMs to not be a competitive
approach for addressing SATD
Toward Automatically Completing GitHub Workflows
Continuous integration and delivery (CI/CD) are nowadays at the core of
software development. Their benefits come at the cost of setting up and
maintaining the CI/CD pipeline, which requires knowledge and skills often
orthogonal to those entailed in other software-related tasks. While several
recommender systems have been proposed to support developers across a variety
of tasks, little automated support is available when it comes to setting up and
maintaining CI/CD pipelines. We present GH-WCOM (GitHub Workflow COMpletion), a
Transformer-based approach supporting developers in writing a specific type of
CI/CD pipelines, namely GitHub workflows. To deal with such a task, we designed
an abstraction process to help the learning of the transformer while still
making GH-WCOM able to recommend very peculiar workflow elements such as tool
options and scripting elements. Our empirical study shows that GH-WCOM provides
up to 34.23% correct predictions, and the model's confidence is a reliable
proxy for the recommendations' correctness likelihood
Automatically Generating Dockerfiles via Deep Learning: Challenges and Promises
Containerization allows developers to define the execution environment in
which their software needs to be installed. Docker is the leading platform in
this field, and developers that use it are required to write a Dockerfile for
their software. Writing Dockerfiles is far from trivial, especially when the
system has unusual requirements for its execution environment. Despite several
tools exist to support developers in writing Dockerfiles, none of them is able
to generate entire Dockerfiles from scratch given a high-level specification of
the requirements of the execution environment. In this paper, we present a
study in which we aim at understanding to what extent Deep Learning (DL), which
has been proven successful for other coding tasks, can be used for this
specific coding task. We preliminarily defined a structured natural language
specification for Dockerfile requirements and a methodology that we use to
automatically infer the requirements from the largest dataset of Dockerfiles
currently available. We used the obtained dataset, with 670,982 instances, to
train and test a Text-to-Text Transfer Transformer (T5) model, following the
current state-of-the-art procedure for coding tasks, to automatically generate
Dockerfiles from the structured specifications. The results of our evaluation
show that T5 performs similarly to the more trivial IR-based baselines we
considered. We also report the open challenges associated with the application
of deep learning in the context of Dockerfile generation
Studying the Usage of Text-To-Text Transfer Transformer to Support Code-Related Tasks
Deep learning (DL) techniques are gaining more and more attention in the
software engineering community. They have been used to support several
code-related tasks, such as automatic bug fixing and code comments generation.
Recent studies in the Natural Language Processing (NLP) field have shown that
the Text-To-Text Transfer Transformer (T5) architecture can achieve
state-of-the-art performance for a variety of NLP tasks. The basic idea behind
T5 is to first pre-train a model on a large and generic dataset using a
self-supervised task ( e.g: filling masked words in sentences). Once the model
is pre-trained, it is fine-tuned on smaller and specialized datasets, each one
related to a specific task ( e.g: language translation, sentence
classification). In this paper, we empirically investigate how the T5 model
performs when pre-trained and fine-tuned to support code-related tasks. We
pre-train a T5 model on a dataset composed of natural language English text and
source code. Then, we fine-tune such a model by reusing datasets used in four
previous works that used DL techniques to: (i) fix bugs, (ii) inject code
mutants, (iii) generate assert statements, and (iv) generate code comments. We
compared the performance of this single model with the results reported in the
four original papers proposing DL-based solutions for those four tasks. We show
that our T5 model, exploiting additional data for the self-supervised
pre-training phase, can achieve performance improvements over the four
baselines.Comment: Accepted to the 43rd International Conference on Software Engineering
(ICSE 2021
Polymorphism: an evaluation of the potential risk to the quality of drug products from the FarmĂĄcia Popular Rede PrĂłpria
Polymorphism in solids is a common phenomenon in drugs, which can lead to compromised quality due to changes in their physicochemical properties, particularly solubility, and, therefore, reduce bioavailability. Herein, a bibliographic survey was performed based on key issues and studies related to polymorphism in active pharmaceutical ingredient (APIs) present in medications from the Farmácia Popular Rede Própria. Polymorphism must be controlled to prevent possible ineffective therapy and/or improper dosage. Few mandatory tests for the identification and control of polymorphism in medications are currently available, which can result in serious public health concerns